home *** CD-ROM | disk | FTP | other *** search
/ CD Ware Multimedia 1995 May / cd Ware (Juegos) Epimundo.iso / DOS / TOOLS / STARTREK.ZIP / CHAPTER.003 < prev    next >
Encoding:
Text File  |  1989-05-15  |  9.4 KB  |  265 lines
  1.         Chapter 3 page 1 STARTREK THE COMPUTER PROGRAM By Joe Kasser
  2.  
  3.  
  4.  
  5.                                     CHAPTER 3
  6.  
  7.         3.1 Converting the Simulation to a game
  8.  
  9.              The problem now is to convert this set of rules into a  game 
  10.         that can be played on a computer.   First consider the  structure 
  11.         of  the  game.   The majority of these games are  not  real  time 
  12.         games.    That  means that the computer waits for the  player  to 
  13.         make  a  move,  then evaluates the  ramifications  of  that  move 
  14.         recomputing the state of all the variables.  After the  variables 
  15.         have  assumed their new states and the actions taken  place,  the 
  16.         simulation then assumes a new state while the computer waits  for 
  17.         the  next  move to be made. In a real time  game  the  simulation 
  18.         model is dynamic, and events occur based on the passage of  time. 
  19.         The  (simulation) game moves along and the player  inputs  modify 
  20.         the state of some of the variables.   This can be demonstrated as 
  21.         follows.  In the static game which waits for the player to take a 
  22.         turn,  a  "move" command will position the Enterprise  in  a  new 
  23.         location  (deducting  the amount of energy used to  get  to  that 
  24.         location  from  the available reserves. The  Enterprise  is  then 
  25.         effectively stationary at the new location until the next  "move" 
  26.         command is carried out.
  27.  
  28.              In the dynamic or real time game, setting the warp factor to 
  29.         move  the  ship will start it moving.  It will then  continue  to 
  30.         move  until either the player intervenes to stop it or change the 
  31.         direction of movement, it collides with something, it runs out of 
  32.         energy, fuel, time   or is destroyed by the enemy.
  33.  
  34.              The  decision to write a dynamic or a static game has to  be 
  35.         made when the structure of the game is established.
  36.  
  37.                   If your terminal cannot be updated in real time, or  if 
  38.         addressing  the individual character positions is  very  complex, 
  39.         you  are probably better off writing a static or none  real  time 
  40.         version  of  the game.   
  41.  
  42.         3.2 The Static Model
  43.  
  44.         The model discussed herein written in BASIC is the static or  non 
  45.         real  time  version.  However  since the game  is  written  in  a 
  46.         structured  modular manner, it wouldn't be too difficult  to  re-
  47.         arrange the modules into a real time version.  The top level flow 
  48.         charts  for both versions of the game are in fact  identical  and 
  49.         shown below.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.         Copyright (c) Joe Kasser 1989
  62.  
  63.  
  64.  
  65.  
  66.  
  67.         Chapter 3 page 2 STARTREK THE COMPUTER PROGRAM By Joe Kasser
  68.  
  69.  
  70.         :    STARTREK
  71.          
  72.         INITIALISE.VARIABLES
  73.         RANDOM.QUADRANT.FOR.INITIAL.POSITION
  74.         INITIALISE.QUADRANT
  75.         LOOP (GAME.OVER.FLAG.SET)
  76.         +    PLAY.GAME
  77.         ENDLOOP
  78.         PRINT.END.OF.GAME.MESSAGE     ;
  79.  
  80.              It  begins with an operation that initializes all  variables 
  81.         and  parameters  used in the game.  The Enterprise is  also  then 
  82.         positioned in a random quadrant, which is initialized.
  83.  
  84.              The  whole game is contained within the LOOP containing  the 
  85.         procedure PLAY.GAME.  The GAME OVER Flag is a signal between  the 
  86.         subroutines  and the main or calling routine.  It is  set  within 
  87.         the  loop  when the game is required to terminate.  The  flag  is 
  88.         tested at the end of the loop, and the game continues as long  as 
  89.         the flag does not signal a termination.  The flag is set when you 
  90.         win  or  lose the game, either by being destroyed  due  to  enemy 
  91.         action,  by running out of energy and dying slowly as  your  life 
  92.         support  systems fail or by winning the game when you succeed  in 
  93.         your mission by wiping out the enemy. 
  94.  
  95.              The  version of the procedure for PLAY.GAME for  the  static 
  96.         model is shown below.
  97.  
  98.         :    PLAY.GAME (STATIC MODEL)
  99.  
  100.         COMMAND.DIALOG
  101.         VALID.COMMAND =?
  102.         YES  (0)  EXECUTE.COMMAND
  103.         NO   (0)  DISPLAY.ERROR.MESSAGE
  104.         THEN (0)
  105.         KLINGONS.IN.QUADRANT =?
  106.         YES  (1)  SHOOTBACK
  107.                   COMMAND.COMPUTER =?
  108.                   NO   (2)  COMMAND.SHORT.RANGE.SENSORS =?
  109.                             NO   (3)  MOVE.KLINGONS
  110.                             THEN (3)
  111.                   THEN (2)
  112.         THEN (1)  ;
  113.  
  114.              The procedure starts with some command dialog that asks  the 
  115.         player  to select a command or move.  The computer waits for  the 
  116.         player  to think of a move and enter it into the computer.   Once 
  117.         the move (command) is entered it is checked for validity.  If  it 
  118.         is  a  good one, the command is executed.  The input  command  is 
  119.         sequentially compared with the allowed ones, and when a match  is 
  120.         found the program flow branches to the relevant procedure.  If  a 
  121.         match is not found or the command was invalid in the first place, 
  122.         an error message is displayed, and the procedure terminates.
  123.  
  124.              After  the command has been carried out, it is the  Klingons 
  125.  
  126.  
  127.         Copyright (c) Joe Kasser 1989
  128.  
  129.  
  130.  
  131.  
  132.  
  133.         Chapter 3 page 3 STARTREK THE COMPUTER PROGRAM By Joe Kasser
  134.  
  135.  
  136.         turn  to do something.  The flowchart thus then shows a  test  to 
  137.         determine  if  any Klingons are present in the Quadrant.   If  at 
  138.         least one is, the SHOOTBACK procedure is carried out, which gives 
  139.         them  the  opportunity to fire at you.  If the move made  on  the 
  140.         current  turn was not a SHORT RANGE SENSOR SCAN (SRS), a  DISPLAY 
  141.         GALACTIC MAP REQUEST (MAP) or a KLINGON STATUS DISPLAY (KST), the 
  142.         Klingons  are  allowed  to  move  within  the  Quadrant  by   the 
  143.         MOVE.KLINGONS procedure.  
  144.  
  145.              The  PLAY.GAME  procedure then terminates.   Each  procedure 
  146.         that  has been defined by a name is usually a subroutine  in  the 
  147.         BASIC language implementation of the game.
  148.  
  149.         3.3 The Dynamic Model
  150.  
  151.              The version of the PLAY.GAME procedure for the dynamic model 
  152.         is  very different.   Here the model executes continuously  while 
  153.         the player changes the state of a number of the action elements.
  154.  
  155.         :    PLAY.GAME (DYNAMIC MODEL)
  156.  
  157.         VISUAL.DISPLAY
  158.         SHORT.RANGE.SENSOR.DISPLAY
  159.         LONG.RANGE.SENSOR.DISPLAY     
  160.         TORPEDO.FIRED =?
  161.              YES  (1)  MOVE.TORPEDO
  162.              THEN (1)
  163.         MOVE.ENTERPRISE
  164.         KLINGONS.IN.QUADRANT =?
  165.              YES  (1)  MOVE.KLINGON
  166.                        SHOOT.BACK
  167.              THEN (1)
  168.         RANDOM.EVENT   ;
  169.  
  170.                In  this  model  we  concentrate  on  action.   The  first 
  171.         procedure  tests  to see if a torpedo was fired, if  one  was  it 
  172.         moves it one sector.  The action of firing a torpedo now  becomes 
  173.         loading the course and current location into an array and setting 
  174.         a  "torpedo  fired" flag for the MOVE.TORPEDO  procedure  to  act 
  175.         upon.   The Enterprise is then moved according to the  navigation 
  176.         data.  If the enemy is present in the Quadrant, the  MOVE.KLINGON 
  177.         procedure  moves the enemy inside the quadrant.  The  enemy  then 
  178.         attacks the Enterprise thanks to the SHOOT.BACK procedure.
  179.  
  180.              The  remainder of the  procedure then performs  the  display 
  181.         function  showing the visual, short range and long  range  sensor 
  182.         displays.   It must now be obvious that the dynamic or real  time 
  183.         version  of the game must be written for a high speed serial  CRT 
  184.         terminal   or memory mapped video display.  The last item is  the 
  185.         RANDOM.EVENT  procedure which contains all the actions that  seem 
  186.         to  happen at random in the passage of the game.   Routines  that 
  187.         are contained in this module include Mr. Spok fixing damaged sub-
  188.         systems and hitting a Klingon Space Mine.
  189.  
  190.              Not  shown is the command dialog.  If the execution time  of 
  191.  
  192.  
  193.         Copyright (c) Joe Kasser 1989
  194.  
  195.  
  196.  
  197.  
  198.  
  199.         Chapter 3 page 4 STARTREK THE COMPUTER PROGRAM By Joe Kasser
  200.  
  201.  
  202.         the PLAY.GAME procedure is fast enough the command dialog can  be 
  203.         tested  once per loop.  If not it should be inserted between  the 
  204.         other  sub  procedures.  This will be discussed  later  when  the 
  205.         static model is fully described.
  206.  
  207.              The  available commands are fewer in this  version,  because 
  208.         the  sensor  displays are constantly on the  screen,  and  Damage 
  209.         control  takes  care  of  itself as  time  passes.    The  player 
  210.         commands are thus as follows
  211.  
  212.         NAV  Navigation
  213.         PHA  Phasers
  214.         TOR  Photon Torpedoes
  215.         SHE  Shields
  216.         RES  Resign
  217.  
  218.              Having laid out the structure of the game from the top,  let 
  219.         us  now look at the bottom up implementation by considering  each 
  220.         command in turn.  Once we have done that we will then take a look 
  221.         at how they link together.
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.         Copyright (c) Joe Kasser 1989
  260.  
  261.  
  262.  
  263.  
  264.  
  265.